With the emergence of 3G mobile telephony, new packet-based communication technologies using IP (Internet Protocol) have been developed to support wireless communication of multimedia. For example, communication protocols in GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) support packet-switched multimedia services, as well as traditional circuit-switched voice calls.
A network architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as a platform for handling multimedia services and sessions in the packet domain, based on IP transport. Thus, an IMS network can be used to initiate and control multimedia sessions for any IP enabled terminals being connected to any type of access networks. A signalling protocol called “SIP” (Session Initiation Protocol, according to the standard IETF RFC 3261) is typically used for handling sessions in IMS networks. A “SIP-enabled” terminal can thus use this standard to initiate and terminate multimedia communications by means of its home IMS network.
FIG. 1 is a simplified schematic illustration of a basic network structure for providing multimedia services by means of an IMS network 100 for a client using a terminal A. In this example, terminal A is a mobile terminal connected to a radio access network 102 and communicates in a multimedia session with another terminal B, even though IMS can be used for fixed terminals as well. Alternatively, terminal A may communicate with a content server or the like, e.g. for downloading some multimedia content therefrom. An IMS terminal is often generally referred to as “User Equipment (UE)”.
The access network 102 is connected to IMS network 100, which is the “home” IMS network of terminal A and therefore handles the session for terminal A. Another similar IMS network 104 handles the session for terminal B. Basically, multimedia services are handled by the terminal's home IMS network even when roaming in a visited access network. In the shown example, terminals A and B belong to different IMS networks 100 and 104, respectively, although they may of course instead belong to the same IMS network.
The illustrated session is controlled by specific session managing nodes 106 in the IMS network 100. These nodes typically include S-CSCF (Serving Call Session Control Function), I-CSCF (Interrogating Call Session Control Function) and P-CSCF (Proxy Call Session Control Function), according to the conventional IMS architecture. Briefly described, a P-CSCF node acts as an entry point towards the IMS network 100 from access networks, a plurality of S-CSCF nodes are assigned to active terminals for managing their sessions using SIP signalling, and an I-CSCF node acts as a gateway for SIP messages from other IMS networks.
The IMS network 100 also includes one or more application servers 108 for various multimedia services, and a main database node HSS (Home Subscriber Server) 110 containing subscriber and authentication data. The various functions of the shown network elements 106-110 are generally known in the art, not necessary to describe here further to understand the context of the present invention.
In the figure, the thick two-way arrow illustrates the communication of payload data or “media” between the two terminals A and B, and the thin two-way arrow illustrates the communication of various control messages between the two IMS networks 100 and 104, typically according to SIP. Each application server 108 supports one or more specific multimedia services such as “Instant Messaging” (IM), “Push-to-talk over Cellular” (PoC) and “Presence”, where SIP signalling is used to control sessions. In particular, presence services basically make data related to an observed client available to other watching clients.
In this description, the term “presence data”, or generally “client data”, is used to represent information on the state or situation of a client and his/her equipment in any predefined respect. Briefly described, presence data of a client is published by storage at an application server generally referred to as a “presence server”, which can be supplied to other clients subscribing to that presence data. The presence data may refer to the following exemplary client states:                A personal status, e.g. available, busy, in a meeting, on holiday, etc.        A terminal status, e.g. switched on/off, engaged, out of coverage, etc.        The geographic location of the client/terminal.        Terminal capabilities, e.g. functionality for SMS, MMS, chat, IM, video, etc.        Terminal selections, e.g. call forwarding, language, etc.        Other client information, e.g. interests, occupations, personal characteristics, moods, personal logos, logo depending on the current mood, etc.        
This type of information is continually stored in presence servers in the IMS network, based on publications of so-called “client events” received from clients or their access networks, whenever any presence data for a client is introduced, updated, changed or deleted. A client may thus also subscribe for selected presence data of one or more other clients which is also handled by an application server in the IMS network.
In this description, the term “client” will be used to generally represent a user equipment (or terminal) and its user. Further, the term “watching client” represents a client that subscribes or requests for presence data (sometimes also referred to as the “Watcher”), and the term “observed client” represents a client that publishes presence data (sometimes also referred to as the “Presentity”) to be available for observation by authorised watching clients.
A SIP message called “SIP PUBLISH” is generally used by observed clients to send their presence data to the presence server for publication. Another SIP message called “SIP SUBSCRIBE” is used by watching clients to subscribe for presence data of observed clients. The SIP PUBLISH message can be used basically in four different cases, namely: 1) to initiate new data, 2) to “refresh” data (i.e. confirming that earlier initiated data continue to be valid), 3) to modify data, and 4) to terminate data no longer valid. The SIP SUBSCRIBE message can be used to obtain presence data either just once or on a regular basis, as determined by a time-out parameter that can be set in that message. If the time-out parameter is set to zero, a notification with requested presence data is obtained just once and the subscription is promptly terminated.
In order to obtain a subscription for presence data of an observed client, the watching client must be authorised by the observed client to receive such presence data, which is controlled by means of presence rules dictated for the observed client. A protocol called XCAP (XML Configuration Access Protocol) can be used to introduce, modify and delete presence authorisation rules in a presence rule database.
FIG. 2 illustrates a conventional procedure for obtaining a subscription for presence data, involving the user equipment A of a watching client and the user equipment B of an observed client belonging to an IMS network 200 comprising a presence server 202 acting for client B. The shown procedure is valid for a standard presence solution defined by OMA-PAG, based on various standards according to 3GPP and IETF-SIMPLE. As shown in the figure, clients A and B are represented by mobile terminals operated by users, even though the described procedure can be applied for fixed terminals as well. It is assumed that client A is initially unauthorised to receive presence data of client B.
A first step 2:1a generally illustrates that the observed client B publishes presence data by sending SIP PUBLISH messages to presence server 202 according to conventional routines, as described above. Certain data for client B can also be sent from client B's access network, e.g. location and terminal status data. The presence data for client B is maintained in a presence database 204, and step 2:1b illustrates that database 204 is updated accordingly in response to receiving the SIP PUBLISH messages of step 2:1a. Steps 2:1a and 2:1b continue throughout in the background, according to prevailing routines.
Client A now wants to obtain presence data of client B, but must be authorised to receive such data. Thus, a standard SIP SUBSCRIBE message is sent to the presence server 202 in a step 2:2, as a request for presence data of client B, which can be expressed as “SUBSCRIBE (Event package=presence, B)”.
Upon receiving the SIP SUBSCRIBE message, the presence server 202 determines whether client A is authorised to receive data or not, by checking presence rules in a database 206, in a following step 2:3. If the rules in database 206 dictate that client A is “allowed”, a SIP NOTIFY is sent to the watching client A with current presence information of the observed client B, but if client A is found to be “blocked”, the subscription attempt is rejected. In this example, it is assumed that the presence rule database 206 contains no authorisation decision for client A, and the presence server may then be configured to send a reject message or simply ignore the request.
Another alternative currently developed, and being illustrated here, is that client B has earlier sent a subscription request (not shown) to presence server 202 for information on any attempts of unauthorised clients to get presence data, which can be expressed as “SUBSCRIBE (Event package=presence.winfo, B)”. The presence server 202 thus notifies client B that client A has made a subscription attempt, by sending a SIP NOTIFY message to client B, in a next step 2:4, which can be expressed as “NOTIFY (Event package=presence.winfo, A)”. Receiving the notification, client B can then decide whether client A should be authorised to receive the requested presence data or not, or optionally only selected parts thereof, by means of a suitable terminal input command as indicated in a step 2:5.
Next, client B responds to the notification of step 2:4 by sending an authorisation decision for client A to the presence server 202, in a following step 2:6, which may be sent in an XCAP PUT message. The authorisation decision could be any of: allow, reject, polite block, etc., which is stored as an authorisation rule in the presence rule database 206, in a step 2:7. If client B just ignores the message of step 2:4, the request would be naturally rejected.
In this example, client B actually allows client A to receive his/her presence data. The presence server 202 therefore finally sends an SIP NOTIFY message containing valid presence data of client B to client A, in a step 2:8, which can be expressed as “NOTIFY (Event package=presence, B)”.
By notifying client B on the subscription attempt of client A, a subscription for presence data can be easily established by sending the initial standard SIP SUBSCRIBE message of step 2:2 above, provided that client B allows the subscription. However, the SIP NOTIFY message of step 2:4 to client B identifies the attempting client A only by a name or network address derived from the SIP SUBSCRIBE message of step 2:2, which the receiving user may not be able to recognise or understand. For example, if an identity of client A is given in the message that indicates a name, e.g. in the manner of “bengt.larsson@telia.com”, client B may possibly recognise it, if known, but not that easily if the identity is given in the manner of “user1224@freeweb.com” or the like.
In order to overcome this limitation, client A can always contact client B separately to identify himself/herself and ask for permission, e.g. by means of a phone call, SMS, e-mail or other messaging mechanism. However, this additional communication would increase the network load and entail extra efforts and costs for the clients involved. Further, the observed client may not have the same type of messaging client capabilities or may be otherwise incompatible. Client B may also apply access restrictions to incoming messages allowing messages from known clients only, thereby preventing client A to communicate in this way if unknown.